The invention is related to editing/creating (as opposed to viewing) multimedia presentations on a portable device. Multimedia presentations are e.g. shown by the device itself or using an external display or communicated between mobile/cell phones or other communication terminals as a part of MMS (Multimedia Messaging Service) messages, as prescribed by 3GPP (Third Generation Partnership Program) technical specifications. (MMS, like Short Message Service (SMS), provides automatic and immediate delivery of personal messages, but allows incorporating sound, images, and other rich content, transforming it into a personalized visual and audio message.) The presentation part in MMS messages can use different formats, but Synchronized Multimedia Integration Language (SMIL, pronounced “smile”) 2.0 is the mandatory format specified by the current 3GPP Release 5 specification. The presentation part includes all media objects (content of the multimedia presentation) as one data object/assembly, describing their layout, timing and other aspects of displaying/playing the media objects on the receiving communication terminal. For example, if an MMS message contains two slides and each contains a text object and an image, the MMS message consists of MMS headers, two image objects, two text objects, and one SMIL object with information to the effect that the message consists of a sequence of two time containers and that the first time container contains parallel media objects (image and text). See FIG. 1 for an example of the structure of a presentation object in MMS.
SMIL is an Extensible Markup Language (XML)-based language. It contains building blocks called modules. The modules which are important from the point of view of the present invention are the so-called structure module, the timing and synchronization module, and the media object module. Each module includes one or more so-called elements and so-called attributes.
The most important elements of SMIL are the so-called “par” and “seq” elements. A par element groups object that should appear in parallel, temporally, in a presentation. For example, if text and an image are shown on one slide at the same time, they will be put within a single <par> . . . </par>pair in a block of SMIL code. A seq element may contain objects that are supposed to be presented to the user sequentially, one after the other, i.e. the second one will not become visible until the first has been displayed/played and is not longer being displayed/played. So the two slides from the previous example would typically be put within a<seq> . . . </seq>pair to indicate that they must be played in sequence. Also the main body element is treated as a seq element when timing is considered. These and some other elements are referred to as “time containers” in the SMIL language. The example above would be encoded as:
<smil><body><par><!--this is slide 1--><img src=”image1.jpg”/><text src=”text1.txt”/></par><par><!--this is slide 2--><img src=”image2.jpg”/><text src=”text2.txt”/></par></body></smil>(This is a simplified encoding; an actual encoding in SMIL would include several more elements and attributes, none of which are relevant to the invention and so are omitted here for clarity.)
Although SMIL permits unlimited nesting of the time containers to create complex timing in a presentation, to ensure interoperability between different communication devices the Open Mobile Alliance (OMA) in the OMA MMS 1.1 and 1.2 specifications has limited the nesting level to two levels. The first level is the main body level and represents the entire presentation. This in turn consists of one or more par elements, which represent slides.
Even though OMA has introduced the above limitations to SMIL in order to ensure interoperability in the early days of MMS, there is no such limitation in 3GPP specifications, which define their own SMIL language profile. The 3GPP profile is slightly less powerful than the full W3C (World Wide Web Consortium) SMIL language 2.0, but regarding the nesting of the time containers it is unlimited too. The deeper nesting of the time containers allows for example making presentation “slides” less static and also allows introducing timing into a slide. For example a presentation may contain a set of slides having content that changes with time. (Thus, in a sense, with more than two levels, a slide may itself be an entire presentation/set of slides, each of which may itself be a new, further presentation/set of slides, and so on.)
MMS terminals available currently on the market are capable of editing or viewing only limited SMIL structures (in terms of time container nesting). The first (top) level of nesting represents the presentation and the second level represents slides. Media items are placed on the second level. Although some handheld terminals (such as cell/mobile phones) can play more complicated content than a two-level presentation, it is impractical today for typical cell phones or other handheld terminals to create more complicated presentations because editing a three-level timing and a two-dimensional space presentations on the typically small screen of a mobile phone or other handheld and making it usable by an average user is difficult. All handheld-hosted editors today are not intuitive or simple and are too time-consuming when used to create complex presentations.
Prior art MMS editors for handheld terminals (such as mobile phones) do not typically allow the content of a slide in a presentation to change with time. In other words, the slides created must be static (except that the media items contained in a slide may change, e.g. video clips, animated .GIF images, etc.). Other, more sophisticated MMS editors e.g. for desktop computers as opposed to handheld devices use an approach in which the entire presentation or animation (if the software is for video editing) is divided into “frames” displayed side-by-side in columns and rows, FIG. 3 showing one row, and a user can navigate between frames (in other words, move to a different point in the presentation) using some sort of a slider widget. An approach using frames displayed side-by-side is useful for computers with big screens, so that the software can reasonably display frames side-by-side all on the same screen. But doing so is not practical on a handheld device because of the small size of the screen.
What is therefore needed is a way of providing instructions for creating a complex multimedia message such as an MMS message on a handheld device, i.e. e.g. a multimedia message that is more than two levels.